我是 Kota，宇鯨智能的創辦人，從 2021 年開始了一人公司，協助中小企業透過 Data / AI 技術進行數位轉型。
我特別關注想要建立新的服務模式、獲取營收的製造業。這背後需要進行大量的流程再造和數位管理，也需要藉由 AI 技術自動化瓶頸的步驟，這些是我特別擅長的領域。
上一篇研究了 OpenAI、Anthropic 和 Palantir 如何投入 FDE。這些公司除了讓工程師深入客戶現場，也試圖將專案經驗轉換成模型、平台或可以重複使用的部署能力。不過，回到我目前服務的台灣中小企業，仍然有一個很現實的問題：即使 FDE 能夠改善軟體交付方式，客戶會因此願意付更多錢嗎？
尤其隨著 Claude Code、Codex 等 AI Coding 工具快速進步，軟體開發的成本與速度都在改變。現在不斷出現開發者利用 AI，在很短時間內重建既有軟體功能的案例。2026 年 10 月，甚至有開發者公開使用 Claude 與 Rust，嘗試開發一系列 Adobe Creative Cloud 的替代工具，包含類似 Photoshop、Illustrator 和 Premiere 的應用程式。雖然這些工具距離成熟商用軟體仍有差距，但相關消息已經足以改變市場對軟體開發成本的想像。（參考：Tom's Hardware）
對企業客戶來說，不論他們是否真的具備自行開發一套系統的能力，都可能因此認為軟體應該做得更快、價格應該更低，連後續客製化修改也不需要花費太多時間。我認為這樣的期待有其合理性，因為 AI Coding 確實已經改變許多軟體開發工作，服務商也應該重新檢查原本的工作方式及報價邏輯。
但如果要進一步理解 FDE 能創造什麼價值，我認為首先需要討論的，是軟體開發的整體交付時間（Lead Time）。
在流程改善的討論中，Lead Time 是一個很重要的指標。從需求提出到完成交付，中間除了實際執行工作的時間，也包含等待、排程、交接及確認所耗費的時間。
我們可以將它簡化成：
Lead Time = 執行時間（Processing Time）＋等待時間（Waiting Time）
這和精實管理（Lean）中的 Value Stream Mapping 很接近。Value Stream Mapping 會檢視一個工作從開始到結束的完整流程，包含實際處理與等待的時間，藉此找出影響整體效率的瓶頸。（參考：Lean Enterprise Institute）
傳統軟體開發常見的分工，是由 PM 負責訪談與釐清需求，設計師完成 UI/UX，工程師根據規格開發，最後再交由測試或使用者驗收。這種分工有其專業上的價值，但也存在大量交接與等待。例如 PM 需要先整理需求，等待設計師排程；設計完成後，再等待工程師開發。開發過程中如果發現規格不清楚，又需要回頭確認。等到使用者實際操作後，可能還需要再經過一次修改與驗收。
AI Coding 大幅縮短了其中的程式開發時間，但如果原本的分工與交接方式沒有改變，整體 Lead Time 未必能等比例下降。
例如一項需求從提出到交付，原本需要十五個工作天，其中實際開發只占五天，其餘十天都花在等待與交接。即使 AI Coding 讓開發時間從五天縮短到一天，整體交付時間仍然需要十一天。這是一個假設性的例子，但可以說明單純提升 Coding 效率的限制。
因此，我認為隨著 AI Coding 逐漸成熟，軟體開發的分工方式也需要一起調整。以前需要 PM、設計師、工程師分別處理的工作，現在某些專案可能只需要一位熟悉業務需求的人，和一位能夠使用 AI Coding 完成開發的人密切合作。在規模較小、風險可控的專案中，甚至可能由同一個具備流程理解與工程能力的人，完成需求釐清、原型開發及初步驗證。
當工作不再需要經過大量交接，需求與開發可以快速往返，整體 Lead Time 就有機會大幅縮短。當然，這不代表所有專案都應該取消 PM、設計師或其他工程專業。複雜的系統架構、資訊安全及正式上線，仍然需要相應的專業把關。真正值得重新檢查的是，現有的角色分工是否造成不必要的等待，以及這些等待能否透過新的工作方式減少。
回到我之前參與的一個 CRM 專案，客戶最初希望導入 AI 智能客服，因此我們開始了解客服如何處理客戶詢問，以及從商機到訂單的整段流程。
進一步盤點後，發現企業當時沒有一套完整的 CRM 系統，許多商機資料都透過 Google Sheets 管理，業務人員需要在不同表格之間進行大量複製貼上。這讓原本的 AI 客服需求，逐漸延伸到 CRM 與 B2B 商機管理流程的討論。
如果一開始就按照「開發 AI 智能客服」進行完整的需求規格與工程分工，可能會在完成部分功能後，才發現還需要處理 CRM、商機管理及後續訂單整合的問題。這樣的情況，即使工程師能夠快速寫完程式，也可能因為需求方向需要調整，增加整體交付時間。
這類專案讓我認為，FDE 的價值之一，是讓理解需求、選擇解決方案、實際開發與使用者驗證之間的距離縮短。當工程能力可以更早參與問題探索，就有機會在需求尚未完全定義時，先透過小範圍的系統實作，確認哪些假設合理、哪些地方需要調整。
AI Coding 則進一步降低這種實驗的成本。過去可能需要等待工程師排程才能完成的 Prototype，現在有機會更快製作出來，讓使用者直接操作，並根據結果重新調整需求。
因此，如果只評估 AI Coding 讓程式開發速度提高多少，可能還低估了它對軟體交付方式的影響。當需求探索與開發之間的等待時間也能降低，FDE 才有機會進一步縮短整體 Lead Time。
這讓我想到一個流傳已久的故事，彭建文前輩和我一個資深資料工程顧問 Laurence 都有提到過。
一艘大船的引擎突然故障，沒有人能夠修復。船東最後找到一位擁有多年經驗的機械工程師。工程師仔細檢查後，拿出一把小錘子，在引擎的某個位置輕輕敲了一下，沒多久引擎便恢復運作。
當工程師提出兩萬美元的維修費時，船東認為價格太高，要求列出明細。工程師將帳單拆成兩個項目：用錘子敲打的費用是兩美元，知道應該在哪裡敲、敲多重的費用是 19,998 美元。
這個故事很適合用來思考現在的 AI 軟體開發，但修理引擎與為企業開發系統，仍然存在一些差異。修理引擎時，問題已經發生，專家的任務是找到故障原因，再選擇合適的修復方式。企業軟體專案則經常 連需要解決的問題都還沒有完全釐清。
例如之前參與的製造業報價系統，客戶希望改善報價效率，但實際討論後，發現報價流程包含標準品項、特殊規格、公式估算、採購詢價及外發報價等不同情況。標準品項可以依既有價格資料處理，部分超出級距的規格可以使用公式估算，但如果超過工廠設備或材料限制，就必須轉由採購詢價，無法單純透過公式外推。
要完成這套系統，除了建立操作介面與計算功能，還需要確認各種業務規則、例外情況，以及如何與既有訂單管理流程整合。AI Coding 可以協助快速完成許多程式實作，但究竟應該解決哪些問題、哪些規則值得自動化、什麼時候應該交由人工處理，仍然需要結合企業現場的資訊與專業判斷。
隨著程式實作的門檻下降，理解客戶需求、判斷問題、選擇合適的工具與系統架構，可能在整體服務中占有更高的重要性。對 FDE 而言，這些工作原本就是深入客戶現場的重要目的，而 AI Coding 則有機會讓工程實作更快跟上前面的決策。
不過，敲引擎的故事只能說明專業判斷具有價值，還無法直接回答客戶願意為這些判斷支付多少費用。尤其當服務商和客戶一開始都還不知道完整答案，需要花時間探索與驗證時，這種價值究竟該如何計價，反而會變得更加複雜。
過去軟體開發常見的方式，是依照投入的人時收費，或是在確認需求後，直接提供固定價格的專案報價。但 AI Coding 的發展，讓我開始重新思考這兩種方式。
按照人時計價，原本的邏輯很直觀，工程師投入多少時間，就依照相應的工時與單價收費。但現在許多程式開發工作可以透過 AI 大幅加速。如果仍然只按照實際投入的人時收費，開發效率提高後，服務商的收入反而可能下降。
當然，需求理解、流程設計與架構判斷仍然需要投入時間，但如果向客戶解釋，因為 Coding 變便宜了，所以需求探索與架構設計的人時單價必須提高，我很難想像這樣的溝通能夠輕易獲得客戶認同。
固定價格也有另一個問題。企業專案的需求經常比最初預期複雜，尤其 FDE 強調深入客戶現場，在真正了解流程之前，很難完整掌握工作範圍。如果在專案開始前就承諾固定價格，服務商可能需要承擔大量未知的整合與修改成本。
因此，另一種值得考慮的方式是階段式交付與計價。先完成需求探索或小範圍驗證，再根據結果決定下一階段的工作範圍與預算。這可以減少一次承諾過多未知需求的風險，但從客戶的角度來看，也不一定具有吸引力。
企業在選擇 ERP 時，通常希望一次處理採購、庫存、生產、銷售或財務等問題。ERP 廠商可以提供既有軟體、功能模組、導入計畫與整體報價，而且客戶往往一開始認為標準化軟體已經可以解決他們的問題，因此希望得到一份相對完整的解決方案。
相較之下，如果 FDE 建議先盤點流程，確認問題，再進行小範圍開發與驗證，客戶可能會擔心最後究竟要花多少錢、整套系統什麼時候才能完成。而且企業未必有足夠的資訊或專業能力，在採購前判斷一套 Total Solution 是否真的適合自己的工作流程。
這一點在我之前參與的 ERP 導入過程中，就有很明顯的觀察。即使企業已經選擇成熟的 ERP，到了實際導入時，仍然需要決定採購流程是否應該先經過請購與審核、不同規格的物料是否應該使用相同料號，以及原本透過備註欄傳遞的資訊，是否應該轉換成正式系統流程。
甚至有些流程在會議中已經確認，直到使用者實際操作之後，才發現仍然需要調整。因此，成熟軟體提供的功能完整性，並不代表企業在導入前就能掌握所有流程問題。
但對客戶來說，一套有完整功能清單、整體報價與預定時程的系統，仍然可能比逐步探索的方案更有吸引力。這也說明，服務商希望透過階段式交付管理不確定性，和客戶希望一次取得完整解決方案，兩者都有合理的考量。
除了工時計價、固定價格與階段式計價，最近也開始看到一些 AI 智能客服採用成果計價（Outcome-based Pricing）的案例。
例如 Intercom Fin 已經採用依 Outcome 計費的方式。一般客服問題解決等成果，每次收費 0.99 美元。它的 Outcome 定義也包含某些完成指定流程或成功交接的情況，因此不完全等同於客服問題已經解決。
Zendesk 則使用 Automated Resolution 作為 AI Agent 的計費單位，依據符合自動解決定義的客服案件計費。Zendesk 也在 2026 年推出分層計費方式，依照 AI 完成的工作類型與價值區分計價。
另一家 AI 客服公司 Sierra，也明確主張依照 AI 完成的成果收費，例如解決客服問題、挽留準備取消訂閱的客戶，或完成其他有商業價值的任務。
這裡有個重要但是很挑戰的問題，如果軟體開發的成本與速度持續改變，是否可以讓服務商的收入更直接連結到客戶實際得到的成果？
例如報價系統，如果能夠將每筆報價的平均處理時間從原本的狀態明確降低，是否可以根據改善成果計價？如果 AI 客服能夠解決一定比例的客戶問題，是否可以依照實際處理的案件數收費？
要注意的是，這些案例主要是已經產品化的 AI Agent 服務，和高度客製化的企業系統仍然有所不同。
企業報價系統上線之後，報價時間是否縮短，除了系統本身，也可能受到使用者配合程度、產品規格複雜度及內部審核流程影響。如果以業績成長作為成果，問題又更加複雜。業績受到市場需求、價格、業務能力與其他因素影響，很難將所有改善直接歸因於系統。
如果服務商承擔了全部開發成本，但最後因為客戶資料不足、內部流程無法配合，導致預期成果沒有發生，這些風險又應該由誰承擔？
因此，成果計價雖然讓服務商與客戶的利益更有機會一致，但也需要事先定義成果、衡量方式，以及雙方各自需要承擔的責任。
整理後，四種方式各自有不同的限制：
| 計價方式 | 主要優點 | 主要困境 |
|---|---|---|
| 工時計價 | 容易依投入計算成本 | AI 提高開發效率，收入可能跟著下降 |
| 固定價格 | 客戶能事先掌握預算 | 需求複雜度可能超出預期 |
| 階段式計價 | 可以逐步探索、確認需求與控制風險 | 客戶可能更偏好一次購買完整解決方案 |
| 成果計價 | 收費可以連結可衡量的商業價值 | 成果定義、歸因與風險分配不容易取得共識 |
這四種方式也不一定互斥。例如部分工作採取固定價格，正式營運後再依照實際使用或成果收費，也是可以進一步研究的方向。
目前我還沒有特別偏好哪一種收費方式，也還沒有足夠的實際案例，可以證明哪一種方式最適合台灣中小企業。不過呢，我認為勢必要同時考慮三件事情：
在接下來文章，我會繼續討論 FDE 的結構性問題。
有興趣知道更多的，也歡迎和我聯繫交流( kota@yujing.io )！
iThome鐵人賽
看影片追技術